✅ SLT Targeted Testing: No relevant SLT tests found for the changes in this PR. No testing required.

Changing writer options significantly improved performance, though some query history related tests fails:

failures:
    tests::worksheets::test_ui_worksheets
    tests::worksheets::test_ui_worksheets_search
    tests::worksheets::test_ui_worksheets_sort

Weird, does the UI get its values from SlateDB or is it directly accessing the objectstore?
Stupid question, it has to go through SlateDB. Weird, because it should be in SlateDBs cache.

Actually tests with that option are flaky, as once there failing 2 of them, then 3. And in CI/CD none is failing

Weird, does the UI get its values from SlateDB or is it directly accessing the objectstore? Stupid question, it has to go through SlateDB. Weird, because it should be in SlateDBs cache.

What about PutOptions TTL could this affect it somehow (a shot in the dark)?

Also ObjectStoreCacheOptions on SlateDb creation

Also ObjectStoreCacheOptions on SlateDb creation

It seems default cache options don't activate this

It seems default options doesn't set up anything or at all if you check out the DbBuilder build? I think we should definitely double check all options, settings, etc for our SlateDb instance.

By default they provide Moka & Foyer caches. Is Foyer worse in our case? We use Moka, however we can even build our own cache if necessary with their DbCache trait.

cc @osipovartem @rampage644 @Vedin

There are also DBReaderOptions which set up their own cache (Foyer or Moka also). But I didn't see where those options are used yet.